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(57) Abstract 

An auction system including a server system (2) for sending current price messages (30) and for receiving bid messages (32), where 
the messages are transmitted using single IP packets, and in particular are transmitted using the User Data Protocol (UDP). This significantly 
improves latency associated with delivery of auction data. The system may be a Dutch auction system which sets a current price for a 
predetermined interval, and determines all bids received during the interval as being at that price. The current price is increased when die 
bids are not accepted. The system also has an interface which includes a clock device for displaying the current price based on received 
current price messages and displaying other data based on received bid reply messages. 
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5 AN AUCTION SYSTEM 

The present invention relates to an auction system and in particular, to a system for 
conducting a Dutch auction or a conventional auction on a communications network such as the 
Internet. 

10 

A number of different auction systems have been established to trade goods over the 
Internet. Some of the systems have proved extremely popular, with one example being the 
system provided by Ebay at http://www.ebay.com. Most of the auction systems are based on 
conventional auctions, where the highest bid is accepted by the auctioning party to complete a 

1 5 sale. Conventional auctions are well suited to disposal of unique and expensive goods, such as 
real estate and automobiles, whereas Dutch auctions are well suited for disposing of a large 
number of less expensive goods, particularly perishable items, such as food and flowers, which 
decline in value over time. Internet auction systems also suffer from an inherent latency problem 
in communications over the Internet which use the Transmission Control protocol/Internet 

20 protocol (TCP/IP). In addition to the communications overhead added by TCP to the basic 
Internet protocol (IP), the auction systems use http transactions to send and acknowledge bids, 
and may even require completion of a CGI form in order to submit a bid. A delay in the 
submission and responses to bids handled in this manner prevents the auction system from being 
a true real-time auction where bids are handled instantaneously by the auctioning party, thereby 

25 giving the auction excitement and life. The latency due to the communications overhead can 
also lead to disputes where one party is in a location which results in its bids being received with 
some delay, whereas another party in a different location is not subject to any significant delay. 
It is desired to provide an auction system and method which are able to alleviate the above 
difficulties, or at least provide a useful alternative. 

30 

In accordance with the present invention there is provided an auction system including 
a server system for sending current price messages and for receiving bid messages, characterised 
in that said messages are transmitted using single IP packets. 
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The present invention also provides an auction system including a server system for 
sending current price messages and for receiving bid messages, characterised in that said 
messages are transmitted using the User Data protocol (UDP). 

5 The present invention also provides an auction method executed using a communications 

system, including sending current price messages from and receiving bid messages at a server 
system, characterised by transmitting said messages using single IP packets. 

The present invention also provides an auction method executed using a communications 
1 0 system, including sending current price messages from and receiving bid messages at a server 
system, characterised by transmitting said messages using the User Data protocol (UDP). 

The present invention also provides an auction method executed by a communications 
system, including: 
1 5 setting a current price for a predetermined interval; 

determining all bids received during said predetermined interval as being at said price; 

and 

increasing said current price when said bids are not accepted. 

20 The present invention also provides an auction interface stored on a computer readable 

storage medium, including: 

a clock device for displaying a current price based on received current price messages; 

and 

an auction display device for displaying data representing the state of an auction based 
25 on received bid reply messages. 

A preferred embodiment of the present invention is hereinafter described, by way of 
example only, with reference to the accompanying drawings, wherein: 

Figure 1 is a block diagram of a preferred embodiment of an auction system; 
30 Figure 2 is a diagram of UDP packets used by the auction system; 

Figure 3 is a flow diagram of a procedure executed by the auction system: 
Figures 4 and 5 are web pages generated by the auction system; and 
Figure 6 is a diagram of the auction system broadcasting a live auction. 
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An auction system includes, as shown in Figure 1, an auction server 2 which is a 
computer system that includes web server software 4 ? and Java™ code to run on a Java virtual 
machine 6 of the server 2. The server 2 may be a standard Unix or Microsoft NT™ machine and 
the web server software 4 may be either Apache™. Netscape Enterprise Server™ or Microsoft 
5 IIS™ or Netscape Fasttrack Server™. The server 2 also includes a number of HTML and/or 
active server pages which are populated with data by the Java™ code and are forwarded as http 
responses 8 to http requests 10 received from a web browser 12 of a client computer system 14. 
The client system 14 may be connected to the server 2 by a communications network, such as 
the Internet, and the web browser 12 may be Netscape Navigator™ or Microsoft Internet 
1 0 Explorer™. Bidding parties are able to use their client system 14 and web browser 12 to access 
and use the auction system established by the server 2. The HTML and Java™ code of the server 
2 controls access to the auction system, operation of the system and generation of the pages for 
display by the client browser 12. as described below. 

15 The auction server 2 executes code on the Java virtual machine 6 to generate pages 

which offer items for auction in lots. The client 14 is able to join the auction by forwarding a 
http request 1 0 to the server's IP address in order to be provided with the pages in http responses 
8. The client 14 on accessing the server 2 in this manner also receives a Java applet by a further 
http response 16 which begins executing on a Java virtual machine 18 of the browser 12 of the 

20 client 14. The applet establishes a user data protocol (UDP) port 20 on the client's system 14 
which is able to communicate with a UDP port 22 of the server 2 established by a reciprocal 
Java program executing on the server 2. Like TCP, which is commonly used with the Internet 
protocol (IP), UDP is a transport layer service. However unlike TCP, messages can be sent using 
a single IP packet whereas TCP always establishes a connection that requires a minimum of 

25 three IP packets, the connection request, the reply and a connection confirmation packet to send 
a message. UDP also only adds a short header to IP packets. UDP provides direct access to IP 
packets to the extent that UDP packets can be considered to be equivalent to IP packets. UDP 
is described in detail in the Internet RFC 768, which is herein incorporated by reference. 

30 The auction server 2 uses the UDP port 22 to multicast offer or current price messages 

30. as shown in Figure 2. The message 30 is shown in Figure 2 as a UDP packet comprising 32 
bytes with a header that includes a message digest field of 16 bytes and a message type field. 
For transmission a UDP header and an IP header are also added to the packet 30. The data 
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payload contains fields representing the number of the current lot a bid number indicating how 
many bids have been made in the current auction, and a current price field which represents the 
current price at which the goods of the lot are being offered. The message type field in the 
header represents that the message is a current price message. A message digest for the rest of 
5 the header is obtained by executing the MD2 message digest algorithm on the remaining fields 
of the packet 30 and then encrypting the result with the digital encryption standard (DES) 
algorithm using a session key for the session between the client 14 and the server 2. The web 
server 4 during a session with a client web browser 12 causes the browser 12 to request the 
generation of a unique session key. A key agreement protocol such as the Diffie-Hellman 

1 0 protocol is used to set up the session key. Alternatively the session key can be created by either 
the client 14 or the server 2 and exchanged using a public key cryptography technique, such as 
signed Java applets or the secure sockets layer (SSL). The message digest is used to confirm that 
the source of the packet 30 is the auction server 2. Before the receiving the packet 30, the client 
system 14 decrypts the message digest and compares it with a message digest determined using 

1 5 the MD2 algorithm on the received data payload to ensure that the two are the same, thereby 
guaranteeing that the packet 30 with a price offer has been sent by the auction server 2. The 
payload of the offer message 30 does not need to be encrypted, as it is available for all clients 
14 connected to the server 2. 

20 At each stage during the auction, on receipt of the offer messages 30, a party can use the 

client system 14 to send a bid message 32 which comprises a UDP packet of 44 bytes, as shown 
in Figure 2. For transmission a UDP header and an IP header are also added to the packet 32. 
Until a bid is acted on the by the server 2, the data contained in the bid message 32 should be 
kept secret so the bid message has its data payload encrypted using DES with the session key. 

25 The payload includes fields for the number of the bid. the lot number of the item for which the 
bid is placed, the quantity or number of items associated with the bid. and the price for the bid. 
The header of 28 bytes includes an encrypted message digest, a field indicating the type of 
message, and two additional fields for a number representing the bidding party or client, and 
data representing the length of the payload before encryption. 

30 

Bid reply messages 34 are also sent as UDP packets with a structure similar to that for 
the bid packets 32. as the reply messages 34 also have their payload encrypted for privacy. The 
reply message 34 informs the bidding party that the bid of the bid message 32. or another bid. 
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has been accepted. The payload of the bid reply message 34 includes fields for the result of the 
bid with data being provided on the bids which have been accepted for the client for the current 
lot and any other lots. 

5 The use of the message format 30 and 32 with UDP is particularly advantageous as this 

significantly reduces latency associated with transmitting auction price and bid information 
between clients and servers of an auction system. The message formats 30 and 32 add minimal 
overhead to network layer IP packets. 

1 0 As discussed above. TCP provides a guarantee that packets sent will be received by the 

intended recipient within a reasonable amount of time, and in the correct order, or the sending 
system is informed of an error and retransmission occurs. To achieve this, TCP insists on the 
receiving system acknowledging all information packets with a reply packet. TCP also adds a 
short checksum to each packet so that the receiving system can reject erroneous packets. The 

1 5 sending system resends packets if it does not receive an acknowledgement within a short period 
of time, and if after several attempts the sending system is not able to receive a successful 
acknowledgement, the user is informed accordingly. 

UDP on the other hand only offers IP packets which can be lost or corrupted in 
20 transmission from a sending system to a receiving system. To address this, the packets sent by 
the auction system that need to be ordered are numbered. If a current price packet is missed or 
arrives out of order, time constraints for a real-time auction mean that retransmission should not 
be undertaken and information should simply be obtained from the next current price packet. 
Accordingly the current price packets 30 are not numbered. However it is important to ensure 
25 that bid packets 32 arrive in order, and so these packets are numbered. Similarly, with regard 
to acknowledgements and replies, only those packets which require replies are replied to. The 
current price packets 30 are not replied to, whereas the bid packets 32 are replied to. As the 
system is an auction system, any reply packets are used to forward information for the conduct 
of an auction. For instance, the bid reply messages 34 are sent as reply packets. The message 
30 digest fields are added to the UDP packets to enable the rejection of any corrupted or garbled 
packets. The system also adds features to the UDP packets which are not provided by TCP and 
are advantageous for an auction system. For example, the message digest is encrypted with the 
secret session key providing an added level of protection over TCP. Furthermore bid messages 
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32 are repeated immediately to ensure they are received in the minimum amount of time, 
without waiting for a reply message, as with TCP. Bid reply messages 34 are similarly 
duplicated for duplicate bid messages 32. 

5 The auction system can be used to establish a Dutch auction, as described below, and 

when doing so, the packet formats 30. 32 and 34 are particularly advantageous in delivering 
real-time price, bid and acceptance information during a Dutch auction. Dutch auctions are 
characterised by their fast pace and their ability to dispose of lots comprising a large number of 
items in a short period of time, and are particularly useful for disposing of perishable items 

1 0 which degrade in value over time. In a Dutch auction, the auctioning party or auctioneer begins 
at a high price for a lot and then descends by steps until a bidder indicates his intention to buy 
at the current price. The successful bidder nominates all or part of the goods on offer. If any 
goods remain in the current lot, the auctioneer increases the offer price by a predetermined 
amount and resumes the auction. The auction for a lot continues in this manner until the stock 

1 5 for the lot is exhausted or a reserve price is reached. Current price information needs to be sent 
rapidly to the client 14 on a continual basis, and as a bid is normally automatically accepted, bid 
price information needs to be received and responded to in a timely and secure manner. These 
requirements are met by the communication method described above. 

20 The auction system begins a Dutch auction for a lot by setting the current price at a start 

price and a variable strikes to 0, as shown in Figure 3 at step 40. The auction server 2 
accordingly generates a Dutch auction page 60, as shown in Figures 4 and 5, which is sent to 
all clients 14 logged onto the server 2 for display by their browsers 12. The page 60 is a dynamic 
interface, having a clock 62 which displays the current offer price and remaining data fields on 

25 the page being generated by a Java applet running on the Java virtual machine 1 8. The interface 
is updated continuously by messages sent from the server 2, such as the UDP messages 30 and 
34. 

The server 2 broadcasts a current price message 30 to decrement the current price and 
30 display a new current price offer as indicated by the message 30. at step 42. The current price 
is displayed and indicated by the hand 64 of the clock 62. The system 2 then waits for a 
predetermined period time. i.e. a price interval, at step 44. and determines whether any bid 
messages 32 have been received at step 46. If no bids have been received and it is determined 
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at step 48 that the current price has not yet been decremented to the reserve price for the lot then 
step 42 is executed again to decrement the current price by sending a further current price 
message 30. The price interval of step 44 is important as it allows all bids received within that 
interval to be treated as being equal in time or isochronous. This ensures the bid process is 
5 equitable and fair for bidding parties located in a variety of distributed locations, 
notwithstanding the reduction in latency provided by use of the UDP packets 30, 32 and 34. The 
interval may be set as desired, and typically may be 1 second. If bids are received within the 
price interval, as determined at step 46, and the number of items bid for in total is less than or 
equal to the available stock, as determined at step 47, then the auction server proceeds to step 

10 50 to execute the sales based on the bid messages 32 received. Once the sales have been 
confirmed at step 50 by forwarding the reply messages 34, the server determines at step 52 if 
all of the units or items of the lot have been sold. If not the strikes variable is set to 0 at step 54 
and the current price is incremented by a sale increment at step 56, by sending the corresponding 
current price message 30, and operation returns to step 42 to continue the auction. The auction 

15 moves to the sale of another lot, at step 49. if it is determined at step 48 that the current price 
has reached the reserve price for the lot, or if it is determined at step 52 that all of the items of 
the lot have been sold. 

The page 60 shown in Figure 4 indicates that the auction is progressing and that so far 
20 there has been a sale of 140 units of the current lot to a bidder Multiflora at $67. A units 
remaining display field 64 indicates that 160 units remain. Within the price interval, two bids 
are then received when the hand 64 reaches S59, one from Allied Flowers and one from Acme 
Flowers for 50 and 60 units respectively. The server 2 treats these bids as being isochronous, 
and as there is sufficient units or items left in the lot both of the bids can be accepted, as 
25 displayed in the page of Figure 5. This is far more preferable than accepting the bid of Allied 
Flowers at $59 and then continuing the auction and hoping that Acme Flowers will again bid 
at $59. The speed of the auction is also enhanced. 

If the number of bids received within the price interval relates to more than the available 
30 units, as determined at step 47, then a determination is made by the server 2 at step 53 as to 
whether the bidders correspond to one bidding party. If the determination is positive, then there 
is no conflict and the remaining stock can be distributed to the bidding party at step 59 and reply 
messages sent at step 50 to confirm the sale. If however there is more than one bidder, then 
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operation proceeds to step 55 where the strikes variable is incremented. If it is determined at 
step 57 that the strikes variable does not equal 3, i.e. this conflict situation has not occurred 
three times before making a sale, step 56 is executed to simply increment the price and continue 
with the auction, on the chance that one of the bidding parties may not repeat their conflicting 
5 bid. This again enhances the speed of the auction. 

If however at step 57 it is determined that the strikes variable does equal 3. three 
conflicts have occurred before making a sale, and step 59 is executed to distribute the remaining 
stock amongst the existing parties as equitably as possible. The auction server 2 will send 
10 corresponding sale messages 34 at step 50, after executing at step 59. the following decision 
steps: 

(i) The number of units bid for each bid is reduced at least to the number of units 
or goods on offer. This is done to deal with any bidder that may have sought an 
excessive number of the goods, thereby distorting the distribution procedure. 
15 (ii) A total number of the items bid for is determined, referred to hereinafter as 

Bidtotal. 

(iii) The bidders are allocated each a number of units based on a truncation of 
(Number of items bid for * Number of items available)/BidtotaL 

(iv) For any units leftover, these are allocated randomly amongst the bidders with the 
20 probability of a bidder getting an additional unit being based on the remainder 

the bidder had in the formula of step (iii) prior to truncation. 

For example, if there are three bidding parties A r B and C and each submits bid 
messages for 5 units, yet there are only 10 units available on offer, the above distribution 
25 procedure may begin with bidder A being assigned 3 units, plus a 1/3 chance of obtaining a 
further unit. If A obtains the further unit, then the remaining 6 units are divided equally between 
B and C If the procedure however determines that A does not receive the additional unit, then 
B obtains 3 units and a 1/2 chance of getting an extra unit, and C will receive whatever remains. 

30 More precisely, the distribution procedure of step 59 executes the following steps: 

( 1 ) Consider the first/next bidder. 

(2) Assign the bidder an initial allocation of: 

Truncate ((Quantity bid for * Quantity available)/Bidtotal). 
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(3) If there is a remainder from step (2), generate a random number between 0 and 1 . 

(4) If the remainder is greater than the random number, the bidder is allocated 1 
more unit. 

(5) The quantity allocated to the bidder is subtracted from the quantity available. 
5 (6) The quantity bid for is subtracted from Bidtotal. 

(7) If there are further bids to be dealt with return to step ( 1 ). 

Applying the above procedure, if there are, for example, three bidders A, B and C and 
each has asked for 5 units, but there are only 8 units on offen each is allocated 2 units plus a 
10 chance to the remaining 2 units. Bidder A is initially allocated 2 units plus a 2/3 chance of 
obtaining a further unit. If A does not obtain the extra unit, the remaining 6 units are divided 
equally between B and C. However if A receives the extra unit then B is allocated 2 units and 
a 1/2 chance of obtaining an extra unit, and C receives the remainder after B has been dealt with. 

15 The above distribution procedure for step 59 can of course be varied, and bidders can 

be given the option of selecting that their bid cannot be adjusted, i.e. either it is accepted on the 
basis of the values of the bid message 30 or rejected. 

The auction system described above is particularly advantageous as it adopts a method 
20 of communication and auction procedures which enhance the speed of auctions conducted by 
the system. The auction system is particularly useful in conducting a real-time Dutch auction 
over a communications network, such as the Internet, which can be used to dispose of a large 
number of goods in a short period of time. 

25 The auction system can also be advantageously used to conduct a conventional auction. 

This simply involves adjusting the system described above to execute the following 
conventional auction steps: 

(a) set the initial offer price to the starting price for the lot; 

(b) send the current offer price for display; 

30 (c) waiting a predetermined amount of time for a bid; 

(d) if a bid is received in the time interval, set the current offer price to the bid price 
and return to step (b); 

(e) if no bid is received in the interval, then declare the lot is ''going once"; 
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(f) repeat steps (c) and (d); 

(g) if no bid is received in the interval, then declare the lot is "going twice"; 

(h) repeat steps (c) and (d); and 

(i) if no bid is received in the interval, then declare the lot "gone r \ sold to the 
5 highest bidder, then move on to the next lot if any and return to step (a). 

For a conventional auction the price clock 62 displays the current bid price to bidding 
parties. The current bid price is adjusted on the basis of the current price message 30 sent during 
step (b). 

10 

The architecture of the auction system can be extended to cater for broadcast of a live 
auction, as shown in Figure 6. The live auction is conducted by an auctioneer 72 with a number 
of bidders 74 present, together with a broadcaster 76 who may also bid on his or other's behalf. 
The broadcaster has a computer system 78 connected to, or part of, the auction server 2. The 

1 5 computer system 78 constitutes a client system 14 and accordingly is able to receive all of the 
interfaces generated by the server 2. In addition, the computer system 78 also includes a 
computer program to transmit current price messages to the server 2, in the same format as the 
current price messages 30. This allows the broadcaster to relay current price information from 
the auctioneer 72 to others using client machines 14 connected to the server 2 over a 

20 communications network, such as the Internet 80. The server 2 instead of generating the current 
price messages simply relays those received from the system 78, as the auction is controlled by 
the auctioneer 72, not the server 2. 

The broadcaster 76 is able to use the program of the system 78 to submit status 
25 messages, in the same format as the bid messages 32. advising on the status of the auction, such 
as "going once", "going twice" and "gone'\ The program also conveys bid messages received 
at the auction server 2 from other parties to the broadcaster 76, so that the broadcaster can place 
those bids with the auctioneer 72. in accordance with the received messages 32. Once the bids 
have been accepted by the auctioneer 72. the broadcaster 76 uses the software to send bid reply 
30 messages back to the clients 1 4 via the server 2. 

The computer system 78 may be connected to the auction server 2 using one or a 
combination of known communication paths, and may also be incorporated into the auction 
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server 2. 

Many modifications will be apparent to those skilled in the art without departing from 
the scope of the present invention as herein described with reference to the accompanying 
drawings. 
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CLAIMS: 

1 . An auction system including a server system for sending current price messages and for 
receiving bid messages, characterised in that said messages are transmitted using single IP 

5 packets. 

2. An auction system including a server system for sending current price messages and for 
receiving bid messages, characterised in that said messages are transmitted using the User Data 
protocol (UDPV 

10 

3. An auction system as claimed in claim 1 or 2, wherein said messages include a message 
digest encrypted with a session key. 

4. An auction system as claimed in claim 3, wherein said current price messages include 
15 a header with said message digest and a message type field, and data fields representing a 

current lot and a current price for at least one item of the lot. 

5. An auction system as claimed in claim 3 ? wherein said bid messages include a header 
with said message digest and fields representing message type, total length of data fields and a 

20 bidden and data fields representing a current lot. a bid. and a price for the bid. 

6. An auction system as claimed in claim 5, wherein said data fields of said bid messages 
are encrypted with the session key. 

25 7. An auction system as claimed in claim 1 or 2. wherein said server system sends bid reply 
messages with fields representing acceptance of bids of said bid messages. 

8. An auction system as claimed in claim 1 or 2. wherein said auction system is a Dutch 
auction system that includes: 
30 means for setting a current price for a predetermined interval; 

means for determining all bids received during said predetermined interval as being at 
said price: and 

means for increasing said current price when said bids are not accepted. 
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9. An auction system as claimed in claim 8. wherein said bids are not accepted when they 
correspond to more than the available stock for an auction lot and there is more than one 
bidding party. 

5 10. An auction system as claimed in claim 9. wherein said stock is distributed and sold when 
said bids are not accepted a predetermined number of times. 

11. An auction system as claimed in claim 1 or 2 r including: 

a clock device for displaying a current price based on said current price messages; and 
10 an auction display device for displaying data based on bid reply messages. 

12. An auction system as claimed in claim 1 1 ? wherein said current price is a current offer 
price which is decreased when said bid messages are not received by said server system. 

15 13. An auction system as claimed in claim 1 1, wherein said current price is a current bid 
price. 



14. An auction system as claimed in claim 1 or 2, wherein said auction system is a 
conventional auction system having means for executing the following: 
20 (a) set a current price to an initial price for a lot; 

(b) send a current price message to display said current price; 

(c) set said current price to the price of a bid message received within a 
predetermined period of time and return to step (b); 

(d) send a message to indicate the lot is going once when a bid message is not 
25 received within said predetermined period of time; 

(e) repeat step (c); 

(f) send a message indicating the lot is going twice if no bid is received within said 
predetermined period of time; 

(g) repeat step (c); and 

30 (h) send a bid reply message indicating sold to the highest bidder when a bid is not 

received within said predetermined period of time and return to step (a). 



15. 



An auction system as claimed in claim 1 or 2. wherein said auction system includes 
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means for executing the following: 

(a) initialising a current price of an auction and displaying the current price on a 
display; 

(b) initialising the value of a price adjustment factor; 

(c) maintaining the current price for a price interval time period; 

(d) decrementing the current price if no bids are received within said interval: 

(e) treating all bids received within any one price interval as being isochronous and 
equal; 

(f) accepting received bids by considering the isochronous bids, an amount of items 
within a lot of the auction, and an amount of items for which respective bids 
were made; 

(g) adjusting the current price displayed on the display by the price adjustment 
factor depending upon whether bids have been accepted: and 

(h) repeating steps (c) to (g) until said items of said lot are allocated to accepted bids 
or the current price has reached a reserve price. 

1 6 ^ auction method executed using a communications system, including sending current 
price messages from and receiving bid messages at a server system, characterised by 
transmitting said messages using single IP packets. 

17. An auction method executed using a communications system, including sending current 
price messages from and receiving bid messages at a server system, characterised by 
transmitting said messages using the User Data protocol (UDP). 

5 18. An auction method as claimed in claim 16 or 17. wherein said messages include a 
message digest encrypted with a session key. 

1 9. An auction method as claimed in claim 1 8, wherein said current price messages include 
a header with said message digest and a message type field, and data fields representing a 

0 current lot and a current price for at least one item of the lot. 

20. An auction method as claimed in claim 1 8. wherein said bid messages include a header 
with said message digest and fields representing message type, total length of data fields and a 
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bidden and data fields representing a current lot a bid, and a price for the bid. 

21. An auction method as claimed in claim 20, wherein said data fields of said bid messages 
are encrypted with the session key. 

5 

22. An auction method as claimed in claim 16 or 17 ? including sending bid reply messages 
with fields representing acceptance of bids of said bid messages. 

23 . An auction method as claimed in claim 1 6 or 1 7, including for a Dutch auction: 
1 0 setting a current price for a predetermined interval: 

determining all bids received during said predetermined interval as being at said price; 

and 

increasing said current price when said bids are not accepted. 

1 5 24. An auction method as claimed in claim 23, wherein said bids are not accepted when they 
correspond to more than the available stock for an auction lot and there is more than one 
bidding party. 

25. An auction method as claimed in claim 24, including distributing and selling said stock 
20 when said bids are not accepted a predetermined number of times. 

26. An auction method as claimed in claim 16 or 17, including: 

displaying with a clock device a current price based on said current price messages; and 
displaying data based on bid reply messages. 

25 

27. An auction method as claimed in claim 26, wherein said current price is a current offer 
price which is decreased when said bid messages are not received by said server system. 

28. An auction method as claimed in claim 26, wherein said current price is a current bid 
30 price. 

29. An auction method as claimed in claim 16 or 1 7. including executing the following: 
(a) set a current price to an initial price for a lot; 
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( b) send a current price message to display said current price; 

(c) set said current price to the price of a bid message received within a 
predetermined period of time and return to step (b); 

(d) send a message to indicate the lot is going once when a bid message is not 
5 received within said predetermined period of time; 

(e) repeat step (c); 

(f) send a message indicating the lot is going twice if no bid is received within said 
predetermined period of time; 

( g) repeat step (c); and 

10 ( h) send a bid reply message indicating sold to the highest bidder when a bid is not 

received within said predetermined period of time and return to step (a). 

30. An auction method as claimed in claim 16 or 1 7. including executing the following: 

(a) initialising a current price of an auction and displaying the current price on a 
15 display; 

(b) initialising the value of a price adjustment factor; 

(c) maintaining the current price for a price interval time period; 

(d) decrementing the current price if no bids are received within said interval; 

(e) treating all bids received within any one price interval as being isochronous and 

20 equal; 

(f) accepting received bids by considering the isochronous bids, an amount of items 
within a lot of the auction, and an amount of items for which respective bids 
were made; 

(g) adjusting the current price displayed on the display by the price adjustment 
25 factor depending upon whether bids have been accepted; and 

(h) repeating steps (c) to (g) until said items of said lot are allocated to accepted bids 
or the current price has reached a reserve price. 

31. An auction method executed by a communications system, including: 
30 setting a current price for a predetermined interval; 

determining all bids received during said predetermined interval as being at said price; 



and 



increasing said current price when said bids are not accepted. 
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32. An auction interface stored on a computer readable storage medium, including: 

a clock device for displaying a current price based on received current price messages: 

and 

an auction display device for displaying data based on received bid reply messages. 
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